Many network tool optimizers, as well as other network devices, utilize standard network routing or switch integrated circuits (ICs) to implement portions of their capabilities. These integrated circuits are able to forward network packets from an ingress port to one or more egress ports based upon information contained within the headers for packets entering the system through the ingress port. The ability to forward packets based upon header information, however, is limited by the characteristics and implementation of the particular network switching or routing IC device being used by the network tool optimizer device. These limitations, for example, make it possible to forward packets based only upon specific fields in the packet header that are recognized by the integrated circuit. Typically, recognized packet header information is limited to Ethernet header information, IP header information, and network layer four (L4) port information. Extremely limited capabilities currently exist in these standard network switching or routing ICs to utilize other fields.
Many packet processing systems, such as Ethernet switch integrated circuits (ICs), routers, and other packet processing systems can classify a packet based upon information in network layer two (L2—data link layer), layer three (L3—network layer) or layer four (L4—transport layer). This L2-L4 network layer information includes MAC (Media Access Control) headers, IP (Internet Protocol) headers and UDP/TCP (User Datagram Protocol/Transmission Control Protocol) port numbers. The processing of this L2-L4 information is typically obtained by extracting address bits from the packet headers and comparing them to a programmable bit mask, for example, using TCAM (ternary content addressable memory) circuitry within the network routing ICs.
In some circumstances, however, it is desirable to classify and forward packets based upon headers or fields that are not supported by the processing capabilities of standard network routing IC packet processors. For example, there may be a need to utilize an address within an IP header inside MPLS (Multi-Protocol Label Switching) tagged packets to classify packets for packet routing and forwarding purposes. There may also be a need to obtain the TEID (Tunnel Endpoint Identifier) in GTP tagged packets to classify packets for packet routing and forwarding purposes. GTP is a GPRS (general packet radio service) tunneling protocol. Standard Ethernet network routing ICs, however, do not have the capability of processing and forwarding packets based upon this information within MPLS or GTP tagged packets. Rather, this information is ignored by these standard network routing ICs. Further, classification and forwarding may also be desired using other information within a packet for which packet processing is not supported by the hardware capabilities of standard network routing ICs.
FIG. 1A (Prior Art) is a block diagram for an embodiment 100 for a prior system that utilizes standard packet routing circuitry 106 to process, classify, and forward packets. As depicted, a network tool optimizer (NTO) device 102 includes packet processing circuitry 105, which in turn includes packet processing controller 104 and packet routing circuitry 106. Packet routing circuitry 106 is implemented using standard network IC packet processors that are configured to support packet processing of packets using data from certain recognized headers or fields within packets formatted using a standard set of packet protocols. This standard set of packet protocols typically includes, for example, Ethernet protocols and internet protocols, such as IPv4 and IPv6. The packet routing circuitry 106 is typically configured to recognize data from certain headers/fields within these standard packet protocols (e.g., MAC headers, IP address fields) and to use this recognized data (DR) to classify the packets and to determine how the packets are forwarded from input (or ingress) ports to output (or egress) ports within the NTO device 102. Other headers/fields within input packets are not recognized by the packet routing circuitry 106 for purposes of packet classification and forwarding. As such, the packet routing circuitry 106 is not able to use this unrecognized data (DX) for classifying and forwarding the input packets.
As depicted in FIG. 1A (Prior Art), the NTO device 102 receives input packets 110 from source devices 108, and these input packets 110 can be formatted using various packet protocols. These input packets 110 are provided to one or more input ports 111 for the NTO device 102 and are then processed and classified by the packet routing circuitry 106. Based upon this processing and classification, the input packets are forwarded to one or more output ports 119 for the NTO device 102 according to packet classification and forwarding control information provided by packet processing controller 104. The output packets 120 are then provided to one or more destination devices 120. As described above, the input packets 110 will include both recognized data (DR) and unrecognized data (DX) with respect to the information within the packet that can be processed by the packet processing circuitry 106 for classification and forwarding purposes. As such, the routing control information 107 from the packet processing controller 105 is limited to classification and forwarding control information related to recognized data (DR) within the packets. As indicated above, this recognized data (DR) depends upon the protocol headers and fields that can be used by the packet processing circuitry 106 for processing, classification and forwarding of the incoming packets. Thus, due to the capabilities and limitations of the packet routing circuitry 106, the output packets 120 can be processed, classified and forwarded to the destination devices 122 based only upon the recognized data (DR) within portions of the packet protocols that are recognized for packet processing purposes by the packet routing circuitry 106.
NTO device 102, therefore, is not able to process, classify, and forward packets based upon the unrecognized data (DX) within the input packets 110. As indicated above, the unrecognized data (DX) represents data in headers or fields within the packets that are not supported by the processing capabilities of the packet routing circuitry 106 for packet classification and forwarding purposes. Because the packet routing circuitry 106 is configured to process only the recognized data (DR) within certain protocol headers/fields supported by the packet routing circuitry 106 for packet processing, the unrecognized data (DX) in other portions of the packets cannot be processed by the packet routing circuitry 106 for packet classification and forwarding purposes. Instead, the packet routing circuitry 106 must ignore the unrecognized data (DX) as indicated by arrow 118 for purposes of classifying and forwarding packets. As such, the packet routing circuitry 106 cannot use the unrecognized data (DX) to process, classify, and forward the input packets 110 to one or more of the destination devices 122.
Destination devices 122, therefore, can receive output packets 120 depending upon the packet classification and forwarding control information provided by the packet processing controller 104 only with respect to the recognized data (DR). The destination devices 122 will not receive output packets based upon classification and forwarding control information that is based upon the unrecognized data (DX), as the packet routing circuitry 106 is not capable of using this unrecognized data (DX) for purposes of packet classification and forwarding due to their internal processing limitations. Examples of packets having data that is recognized and unrecognized for packet processing purposes by standard packet routing circuitry is now discussed with respect to FIGS. 1B and 1C.
FIG. 1B (Prior Art) provides a diagram for an example TCP/IP formatted packet 150 having headers that are typically recognized by standard packet switch ICs. In particular, as shown in FIG. 1B (Prior Art), example packet 150 includes a MAC header 152 (e.g., that may be included as part of an Ethernet frame header), an IP header 154 (e.g., IPv4 or IPv6 header), a TCP/UDP header 156 and a payload field 160 along with other possible fields 158. Typically, packet routing circuitry 106 will be configured to process and route packets based upon information in the MAC header 152, the IP header 154 and the UDP/TCP header 156. These three headers are recognized by the packet routing circuitry 106 for purposes of packet classification and forwarding, while the payload field 160 and the other fields 158 are typically not recognized for purposes of packet classification and forwarding. Thus, only data (DR) in the recognized portion 162 of the packet 150 can be used for packet routing, while data (DX) in the unrecognized portion 164 of the packet 150 is ignored by the packet routing circuitry 106.
FIG. 1C (Prior Art) provides a diagram for an MPLS tagged TCP/IP formatted packet 170 that includes an MPLS header that is typically not recognized by standard packet switch ICs for packet processing and forwarding. In particular, as shown in FIG. 1C (Prior Art), example packet 170 includes a MAC header 172, an MPLS header 174, an IP header 176, a TCP/UDP header 178 and a payload field 180. It is noted that other fields could also be included if desired. MPLS tagged packets typically represent an unrecognized protocol for standard network routing ICs. As such, due to the MPLS header 174 being inserted into the packet 170, the remaining portion 184 of the packet 170 will be unrecognized by the standard packet routing circuitry 106 for packet processing and forwarding purposes. Thus, only the recognized outer portion 182 (e.g., MAC header 172 in this example) can be used for packet classification and routing by the packet routing circuitry 106, while the unrecognized portion 184 is ignored by the packet routing circuitry 106. Thus, if MPLS enabled packets are forwarded to the packet routing circuitry 106, as the packet routing circuitry 106 is not MPLS capable (e.g., does not have the ability to parse MPLS tagged packets to locate the TCP/IP header information), the packet routing circuitry 106 will not be able to classify and forward packets based upon information in the IP header 176 or the TCP/UDP header 178.
To address the need to process unrecognized portions of packets for packet classification and forwarding purposes, some systems support classification of packets based on custom offsets. A custom offset is used to select a field in the packet based upon a fixed index value from the beginning of the packet. This solution, however, is extremely limited for a number of reasons. One reason is that the availability of these custom offset capabilities is restricted to a small number of pattern definitions. Another reason is that the exact position of the desired field must be known and must remain fixed for this method to work properly. However, for many protocols, the packet formats are variable in length and the exact location of a particular field is not in a fixed position in every packet.
While more sophisticated packet processing ICs could potentially be designed that add processing recognition for currently unrecognized portions of packet protocols, supporting every available protocol or protocol variation would be extremely complex. In addition, data within new protocols would still be unavailable until an IC manufacturer chose to add these new protocols to the processing capability for their packet processing network IC devices.